(navigation image)
Home American Libraries | Canadian Libraries | Universal Library | Community Texts | Project Gutenberg | Children's Library | Biodiversity Heritage Library | Additional Collections
Search: Advanced Search
Anonymous User (login or join us)
Upload
See other formats

Full text of "mit :: lcs :: tm :: MIT-LCS-TM-010"






INTERACTIVE DESIGN COORDINATION FOR THE 
BUILDING INDUSTBT 

Janes N. Jackson 



MAC Technical Memorandum 10 
June 1970 



Massachusetts Institute of Technology 
PROTECT MAC 



oust 



■#..■ 



&*.: 



Unnumbered Blank Page 



Note: This page is an unnumbered 
blank used to preserve the printed 
appearance of the author's original 
document. It is the back side of the 
previous numbered page. 



g».*V' 'TPW^p;^^:,- ■,: 



^ 



In -tmrmut Iv* QMMIID. CflOfd 1 Mil gfl ■ jftfc lfr& 

Bull dim I ndust ty 



Techn I cal Mefnorane'um 

. ■' ' b y v ■' 

James N. Jackson 



June 22, 1970 



Department of CIW1 Enflneertni 
Nasiaetiutetts 1 net! tate of Techno 1o«y 



ill 



Unnumbered Blank Page 



Note: This page is an unnumbered 
blank used to preserve the printed 
appearance of the author's original 
document. It is the back side of the 
previous numbered page. 



Abstract 



The problem of effective communication in the process 
of building design and construction is widely recognized. 
The involvement of several design disciplines combined with 
the tendency for designers to work in distinct offices 
results in little capacity for them to investigate the 
Influence of their design decisions on other design areas. 

One of the responses to the need for effective 
interaction in the use of computers for a design project Is 
the supersystem concept proposed for I CES, the I nte^rated 
Civil Engineering System. The supersystem Is defined as the 
cooperat ive effort on the part of the designers of several 
problem oriented computer capabilities to implement project 
oriented capabilities by allowing each of their problem 
oriented subsystems to reference a single file of project 
data. The supersystem would allow design interaction by 
having each of the problem oriented computer subsystems 
reference a single file of information specifying the 
project. 

Future work in the application o^ computers to 
interactive and project oriented design in the building 
industry will have to concentrate on the file structure to 
be used in the impl ementat ion of a computer building Jesi xn 
suoersystem. 



Acknowledgment 



Tfie w6rk dl«§icr1%«cr herein :-*•*;* sirpsorte* by the Of flee 

fcf «%v*1RaSear en under* extract NO0Ot^6f?*^-O276-O002. The 

3: *a*fe%rth *s bet n« bain* ©arrletf oat as a Ph^*>i • thesis I n -the 



..: f - 



CfWl fhslheeftnt Systems Laboratory of the 1*part<n«»nt of 
^ ^8fvH Engineering, Maasiehusettt institute o* Technology. 
lst ^e researeft has been supervfset by Professoi- Kenneth F. 



Vf 



He|n$chm1dt. 






¥1 



The process of building design and construction 
involves much handling and manipulation of data. What 
starts out as the single desire of a client for a building 
develops into a full set of working drawings and specifi- 
cations by the end of the design Qhase of the process and 
ultimately finishes as an existing builling. When one 
examines the data flow in the building process in light of 
the data manipulating and storage capabilities of the modern 
electronic digital computer, one expects at first to find a 
broad utilization of the computer throughout the building 
industry. Yet when one examines the degree to which 
computers are actually used in the building process, the 
findings are generally very disappointing. Few of the 
design disciplines involved with the building process make 
any significant use of the computer and even in these few 
instances, the applications are in completely isolated 
areas. While many design areas involved in building design 
have been considered for computer implementation, most 
efforts have been at the proposal stage only. The two major 
exceptions have been the areas of structural analysis and 
construction project scheduling for which large scale 
systems have been implemented. 

The reasons for the pattern of usage that one finds 
reflect problems both of economics and degree of difficulty. 
As would be expected, engineers have attacked those problems 



first that seemed most promising of solution. Since both 
structural analysis and construction scheduling arp quite 
straightforward in an analytical sense and require much data 
processing, they were computerized first. More significant, 
however, is the fact that these two areas are the exclusive 
domains of two distinct segments of the building process, 
the structural engineers and the contractors. Each invested 
in the software which It felt would make its operations more 
efficient. Neither was particularly motivated to spend 
money to make the job of someone else more efficient. 

The reasons for this pattern of usage can also be 
found in the approach taken by designers of computer systems 
to the whole question of information. The techniques for 
information handling developed for the analytic problem- 
solving systems have in the past almost never considered 
Information requirements beyond the scope of the system 
being implemented. There has been little motivation to 
consider the information requirements of other systems 
because, first, there were few enough of these systems 
Implemented on the computer to begin with, and secondly, 
there had simply been no co-ordination which would result In 
the information being used even if it were made available. 
Furthermore, information has generally been structured so as 
to optimize processing in view of the algorithms used by the 
subsystem structuring it. 

Information has always been considered as a static 



collection of data values which were inout at the beginning 
of a computer run and completely pursed from the computer at 
the end of the run. There has been almost no attemnt to 
view information from the point of v i r>w o f the project, as a 
highly structured complex which starts as a single ilea an 1 
which ends after great development as an extremely complex 
set of drawings and specifications. In those few instances 
where data has been organized by a computer system on 
secondary storage, it has been done in such a way as to be 
of use only to the system which so organized it. 

Building data management, then, is an attempt to 
solve the very complex problems of automating the flow of 
information between various problem oriented comouter 
capabilities used in the design and construction of 
buildings, computer capabilities both existing and proposed. 
Building data management is the concent of data transfer 
applied to the realm of building systems. Data transfer 
attempts to make It possible for independently conceived and 
independently executed computer systems to communicate their 
results with each other. 

Qata Transfer 

The concept of data transfer is not a new one. The 
designers of ICES, an acronym for the INTEGRATED CIVIL 
ENGINEERING SYSTEM (1), have attacked the problem t t -Int.? 
trnnsfer from the very beginning of their effort. The ICES 



It 

system was visualized as a computer oriented system used bv 
a collection of problem oriented subsystems (2). The 
analogy was made to a wheel in which the system comprised 
the axle/ the various subsystems the spokes, and lata 
transfer was to have been a kind of rim uniting all of the 
subsystems via communications capabilites (see Figure 1-1). 
However, If one examines Ices System Hasten (3), the 
guiding ohilosophy for the ICES system, one discovers that 
there are two areas of the system that were not generally 
implemented. They are the relational data structure 
capabilities CO and data transfer. For several years much 
work was put Into the Implementation of both of these areas. 
While some results were obtained in the former area (5), no 
real working system of any capability resulted In the 

1 atter. 

In the first efforts to implement data transfer, the 
ICES researchers attacked the general problem of Information 
flow within the computer. The work was motivated by their 
strong feeling that subsystem designers should be given full 
freedom for design of in-core data structures most suited to 
the problem and algorithms with which they were working. 
Yet, when these Independent systems attemoted to each solve 
a different aspect of the same project, the need arose for 
them to communicate results with each other. The early work 
resulted in a proposal for a Oata Teftnftion Language (6), 
but most felt that an appropriate solution to the problem 









ICES 
SYSTEM 










\ / 


\ / 




* / 


S 


"N. 


\ / 








* 


*S 








BUILD 






STRUDL 






SUBSYSTEM 






SUBSYSTEM 






\ 


\ 
\ 






/ 
/ 


• 






PROJECT 






SUBSYSTEM 




DATA TRANSFER 


FIGURE 1-1 


ORIGINAL CONCEPTION 


OF 


ICES SYSTEM 


- J 



was still yet to be found. In the interim, of coure, data 
transfer was actually acomplished by having the engineer 
using the various subsystems on a project manually transfer 
information from the printout of one set of results to the 
problem language input of the second subsystem (See Figure 
1-2). 

In 1968, Lons (7) performed a study of the efforts in 
data transfer in the context of the ICES system. His major 
conclusion was that while the attempt to solve the problem 
of general data sharing between computer systems had borne 
little fruit, there was some reason to be hopeful th^t a 
less general approach to the problem mi ^ht give bettor 
results. He distinguished between the concepts of the 
system and the subsystem and introduced the concent of a 
supersystem. The system is comprised of those capabilities, 
generally oriented toward strictly comouter tasks, tint ar^ 
used by all of the subsystems. Subsystems are comprised o^ 
capabilities oriented toward some specific engineering 
problem area. The suoersvstem is tiffined as a ijroun of 
loosely organized subsystems, each oriented toward a 
specific problem area, but jointly working towar I ths soal 
of a project implementation, principally by sharing a common 
data base stored permanently on a secondary storage device. 
It is the matter of the orientation, problem versus project, 
that distinguishes a subsystem from a supersystem. Thus, 
while STRUDL, the structural design language. Is capable of 



ICES 
SYSTEM 



BUILD 
SUBSYSTEM 



STRUDL 
SUBSYSTEM 



PROJECT 
SUBSYSTEM 



FIGURE 1-2 
WORKING VERSION 

OP THE 

ICES SYSTEM 



analyzing and selecting members for the structural frame for 
a building, it is not capable of taking the entire hulldln?; 
project or even the structural part from inception to 
completion. The building design comprises many problem 
areas, each of which might require a subsystem of the slz? 
and complexity of STRUDL. 

The implementation of data transfer is imoortant not 
only for the concept of a supersystem but for the way that 
engineering is practiced. Engineers, while in school, solve 
problems. Each problem is a close look at some small, 
specific engineering task. When the problem is solved, the 
answer is graded and no more is done with it. Fnr.tneers, as 
practicing professionals, work on projects. They, too, 
solve problems. In distinction to the work of students, 
however, the answers to their problems are integrated Into 
the larger project effort. These answers are considered In 
their ramifications with other "answers" for other problem 
areas of the project and must be considered as part of all 
the project data. 

Computer efforts in engineering to date hive been 
aimed at giving nroblem solving capabilities. And just as 
looking at an engineering project as a series of problems 
fragments the concept of a project effort, so have these 
computer capabilities tended to fragment the work that can 
be done for a project with a computer. This can be observed 
In the tendency of engineers to require that a problem be of 



sufficient size or complexity In order to justify solving it 
with a computer. The fragmentation hss put an artificial 
barrier between the engineer and his problem solving tool. 

Now in order to overcome the tendency toward 
f ragmentat Ion, in order to develop project oriented computer 
capabilities or supersystems, the whole approach of 
engi neer in? computer development must be re-examined. 
Engineering computer technologists can re-orient the! r 
efforts and work toward the development of project oriented 
subsystems - unique, al 1 -encompass i ng computer systems. 
These would be large scale efforts and might well result, 
for example, in a STRUDL-like subsystem for bridge design, 
another STRUDL-like subsystem for building design, a third 
for tranmission tower system design, and so forth. The 
difficulty with this approach Is the duplication of effort 
that is required to develop unique subsystems for each 
project area. The development of the STRUDL subsystem as a 
problem oriented capability extended over five years. The 
duplication of that effort several times for different 
project areas is worthy of little consideration. 

Another approach to implementing project oriented 
capabilities is specifically that of the supersystem. Each 
project area would have not a unique computer capability but 
rather a unique project data structure. Thus computer 
subsystem developers would continue their current 
orientation of developing problem solving capabilities.- But 



ICES 
SYSTEM 



SUBSYSTEM A 



SUBSYSTEM B 



PROJECT AREA I 

SUPERSYSTEM 
DATA FILE 



SUBSYSTEM C 




PROJECT AREA 2 

SUPERSYSTEM 
DATA FILE 



-©- 



OATA TftANtrilt 
FAOILITV 



FIGURE 1-3 



ICES SUPERSYSTEMS 



each of these problem solving capabilities would have 
additional, satellite features that would allow for the 
implementation of data transfer between the subsystem and a 
specific project data file. The existing subsystem would be 
Integrated with a new supersystem by the implementation of 
the satellite data transfer capabilities for the new project 
data file (See Figure 1-3). 

IhS. Bui Idine Industry 

In the United States, the estimate for the total 
value of construction durine; the year 1970 is set at $90 
billion (8). Table 1-1 gives a breakdown by project type of 
the estimated value of building construction during the same 
year but excluding one and two family dwellings. The same 
estimate predicts a greater than 109 percent increase In 
construction value during the decade 1970-1980 to a value of 
$193 billion. The estimate of the gross national product of 
the United States for the years 1970 =ind 1980 given by the 
estimate are $900 billion and $1,980 billion resoect 1 vely . 
Furthermore, in the United States the industry is comoose:! 

of: 

more than 900,000 contractors and 1,500,0^0 
subcontractors employing over 3,000,000. They are 
supplied by a myriad of other Industries employing 
large numbers, such as the 2«+0,000 employees of 
sawmills and planning mills, the 60,000 In millwork 
and related products, and the 260,000 who manufacture 
equipment. To handle financial, insurance, and real 
estate dealings requires another 1,100,000 people of 
whom more than 6u0,000 are In real estate alone. The 



TABLE I-] (9) 

Forecast of Construction Contracts - 1970 
Mill Ions of Dol lars 

Total Construction * $52,225 

Heavy Construction $16,875 

Non-Residential 3ul Iding 26,10 

Manufacturing $5,000 

Commerical 8,700 

Educational 6,000 

Medical 2,700 

Government Servi ces 1,000 

Recreational, Religious, Etc 2,700 

Residential * 9,25 

Apartments 7,600 

Dormitories 900 

Hotels and Motels 750 



* Excludes one and two families dwellings. 



building design professions incl ude 30,000 registered 
architects and 75,000 engineers plus a large number 
of specialists. Manifestly the industry is lar^e but 
diffuse, and consists of a loose agglomeration of 
mostly small units. The number of design- 
construction firms with an annual volume greater than 
$500 million can be counted on the fingers of one 
hand. Few materials and equipment producers rank 
among the nation's 500 largest industrial firms. (10) 

The technical areas required in the design and 
construction of a large building are amazingly diverse. One 
can consider the professional and economic interests of the 
building industry as falling into one of four general 
categories : management, design, construct Ion, and f i nal 1 y 
operation and maintenance. 

The realm of management includes, first of all, the 
cl lent or owner. The cl i ent is the prima movens of the 
entire industry. It is he who dictates the kind and quality 
of building depending on his needs and financial backing. 
Owners range In size from the private, single home builder 
through developers of capital investment motivated 
skyscrapers in large metropol Itan centers and the Federal 
government with all of Its resources. 

Included in the realm of economics, however, are many 
other professions concerned with building. These include 
planning boards for urban areas, financiers (including 
banks, insurance companies, pension and welfare funds, and 
government mortgage financing agents), real estate 
developers, zoning commiss ions, accountants, and the like. 

The second realm of the building Industry is that of 



1" 



design. Traditionally, the management of design h=js been in 
the hands of an architect who acts as the client's agent for 
both design and construction. 3ut iue to the wMely 
divergent and highly technical nature of many asoscts of 
building desicrn, the architect (excluding one an.1 two 
dwelling housing, which represents about one-half of the 
construction dollar value) requires the assistance of 
professional consultants in the engineering areas. Thesp 
generally include the structural engineer, the foundation 
engineer, the mechanical engineer, the electical engineer, 
and specialists in the areas of cost estimating, interior 
design, acoustics, illumination, and landscaping. 
The third realm of the industry is that of 
construction. The construction phase of the building 
project has traditionally been managed by the architect, but 
the prime agsnt here is the general contractor. The general 
contractor, like the architect in the design realm, uses 
specialized sub-contractors to perform the highly technical 
phases of the construction. These sub-contractors include 
plumbers, heating and air conditioning specialists, 
electrical contractors, plasterers, stone masons, 
carpenters, roofers, structural steel erectors, and 
foundation contractors, among others. 

The final realm is that of operation and maintenance. 
Included here are the operations engineers required to keep 
large mechanical and electrical systems for buildings 



11 

functioning properly/ cleaning crews, security personnel, 
and the construction trades required for repairs and 
modi fi cat ions. 

It should be clear that this diversity of economic 
interests and intellectual disciplines involved in the 
building industry lead to a fragmentation that exists on 
three levels. There is a f ragmentat i on of personnel. The 
nature of building design alone is such that one can never 
expect to see a single person being able to do the entire 
design. There Is a fragmentation of location. For the most 
part as the profession is currently carried on, the 
participants In the design and construction stages each have 
separate offices, sometimes even to the extent of being 
located In different cities. And finally, there is a 
fragmentation of goals. What may well be the best 
structural design can lead to a definitely sub-optimal 
mechanical design, and vice versa. What appears best in 
terms of initial cost may be very poor when considered in 
terms of long term costs. 

The major consequences of this fragmentation ar& 
three. By far the most important and at present the most 
widely recognized consequence Is the communication problem. 
Communication is a basic aspect of the design and 
construction of buildings, whether all of the design 
participants work in a single office or not. The range o^ 
design disciplines dictates that professional interaction 



I? 

take place. The building process typically starts as the 
desire of a client for a building and is developed through 
interviews between the client and the designer, through the 
various design stages, to a fully developed set of contract 
drawings and speci f I car ions . A second consequence of 
fragmentation and one that follows also from the 
communication problem is that of sub-optimization of design. 
A less than perfect communication between the principal 
designers makes it impossible to estimate how their design 
decisions affect each other and consequently how such 
decisions affect overall cost for the client. The problem 
of optimization in building design is as much a matter of 
communication as it is of mathematics. And finally, a last 
consequence of fragmentation is duplication of effort. As 
currently practiced / the duplicate review of drawings and 
specifications for cost estimating by architects and bi-Min- 
by contractors is typical of this duplication of effort. 
Consider the kinds of Incidents that occur in the 
current state of building design. The structural and 
mechanical engineers, having arrived at initial, compatible 
configurations for the structural frame an:i duct system, 
return each to his own office where detail design continues. 
Later the architect informs the mechanical engineer that 
certain changes have occurred in the specification of 
materials for an irea, thus changing the heat loads and 
requiring in turn a ]arF,er duct servicing the area. If the 



mechanical engineer fails to confer with the structural 
engineer again, as happens sometimes when the design is 
rushed, the conflict surfaces only when the contractor 
discovers that the duct is supoosed to go through a 
structural beam. 

One of the reactions to this fragmentation has been 
the tendency of late to combine in one firm all of the 
principals involved in the building industry - financier, 
architect, engineers, and contractor. This reunification at 
least within the same firm helps alleviate some of the 
problems resulting from the fragmentation. Many of the 
goals are thereby consolidated and the problem of 
communication is generally that much lessened. 

The supersystem concept discussed above is another 
reaction to this problem of fragmentation. The supersystem 
proposes to consolidate all of the information about a 
project in a central file of data where it is available to 
all design participants at the same time. Furthermore, the 
availability or data to all designers potentially allows for 
studying the effects of design decisions made in one design 
area on the other aspects of the overall lesion. Thus 
engineers can design in terms of overall project goals 
rather than the more immediate goals of just their own 
discipline area. Finally, the devel ooment of 
telecommunications for computers whereby engineers using 
only low cost terminals in their offices can use the power 



of large computers and data files literally across the 
country, will help in the matter of locational fragmentation 
where it continues to exist, 

jh& Building Process 

Having viewed building construction from the 
viewpoint of an industry, one can take a slightly different 
approach and view the same thins from the viewpoint of a 
process. Considered as a process, building is composed of 
various phases. 

The Royal Institute of British Architects (11) has 
Identified twelve stages of building activity. These stages 
are only an attempt to give a general classification to the 
phase of activity most prevalent at the instant, and there 
is no claim that there are distinctly recognizable points of 
transition between the stages or that all designers are even 
in the same stage at the same time. The phases of the 
building process Identified by the Institute are: 



Inception - First meetings with client and 
establishment of design team. 

Feasibl 1 Itv - Preparat ion of first outline from 
interviews with client and assurance that outline is 
feasible. 

Out! ine Proposal - Further detailed study of client's 
requirements, costs of project, and approaches to 
layout, design, and construction. 

Scheme Design - Final development of preliminary 
design, including full design by architect and 



IS 



preliminary design by engineering designers. 

Deta i 1 Pes i gn - Final dec i s ions on all des i gn 
matters . 

Product i on I nforma t ion - Preparation of final design 
d rawi ngs and specifications. 

Bills of Quanti t ies - Preparation of Tills of 
Quantities for construction bMs. 

Tender Act ion - Bid ii ng by gera ral contractors. 

Project Plann i ng - Construction co-ordination between 
general contractor and his sub-contractors. 

Qperat ions on Si te - Actual construction. 

Comol et i on - Completion of construction. 

Feed-back - Anal ys i s of des i gn, const ruct i on, and 
operation of building during its life. 



Thisdistinction between various phases of the 
bui 1 di ng process is important. Clearly, the probl ems an*1 
even the nature of communi cation differ during the various 
phases of buil di ng. At inception, ideas and data are few, 
highly unorganized, constant 1 y changing, and even geometry, 
a fundamental aspect of all building data is in a very fluil 
state. By the start of preliminary design, most of the 
geometry has firmed up, and the real problems of 
commun ication and interaction among des i priors become the 
most important aspects of the information. "y final design, 
the sheer vol ume of i nfornat ion has become its most critical 
aspect and it is that aspect which extends through the 
construction phases. It is this evolving characteristic of 
but 1 ding i n format ion (the same hoi ds for the i nfornat ion for 



1 * 
any engineering project) that makes the subject of oroject 
data management such a difficult one. These sane changing 
characteristics will dictate explicit requirements for any 
attempt at automated data management as will become evident. 

Why LLs£ Computers In Dl£ ?MJ1dinfi PrQCSSS 

The very fundamental question of why the computer 
should be used at all in the building process is one that 
should be faced. In this age of mass computerization it 
might seem strange that such a question be phrased/ but as 
the complexity and cost of proposed computer systems grow, 
more and more are coming to ask just that question. 

The computer with its allied software is just another 

among many potential tools for those engaged In the building 

process. Recause of its tremendous potential for extremely 

fast calculations and larse capacity data man I oul 3t ion, 

however, the computer stands as a particularly significant 

tool in the collection of the building designer and 

contractor. As Miller has stated it: 

Computers are the key to a systems approach 
to civil engineering. The nature of contemporary 
projects is so lar»o, and there are so many complex 
factors and components - all these different kinds of 
Information must be tied together, and the only way 
you're going to do it is by computer. I f m talking 
about using computers as I nf ormat ion management 
devi ces and not as merel y computat ional tool s. Onl y 
about 10% of our probl ems are computat ional by 
nature, the other 90% are problems of Information 
storage, control, and manipulation. (12) 

There is little question of the computer's canablltty 



1 7 



to store information. Consider, for example, the IBM 
System/360, Model 65, computer. Configured with one million 
bytes of core storage, a model 2301 drum unit, a model 2 3 1 *# 
disk stroage unit, and a model 2321 data cell drive, such a 
system has nearly 500 million characters of on-lin-* storage: 
one million characters of the storage can be accessed in 
less than one microsecond; five million characters of 
storage can be accessed in less than ten milliseconds; over 
sixty million characters of storage can be accessed in less 
than one-tenth of a second; and all of the nearly one half 
billion characters of storage can be accessed in just over 
one-half second (13). Understandably, no one yet really has 
any feeling of how many characters of data would be required 
to completely describe a building design. But there Is 
little doubt that the computer will meet the task, at least 
as regards capacity. The situation looks even more hopeful 
with speculation that the next generation of computer 
hardware will improve the cost/performance ratio of computer 
systems by a factor of from six to twelve over the last 
generation of hardware (14). 

Context qL t±L£ Current Effprt 

The task of developing automated data transfer for 
the building industry is truly a monumental one. The size 
and complexity of the industry combined with the range of 
disciplines that are involved in financing/ designing, and 



18 



constructing buildings has lead to much hesitancy to even 
attempt to tackle the problem. Clearly no one effort will 
be completely successful in such an undertaking and the 
current wotk is just the beginning of what will have to be a 
long process of research and evolution. The current effort 
has been as much an attempt to further define the problem as 
it has to develop a working solution. One of the things 
that has become clear is that the solution will be an 
evolutionary process rather than a completely developed 
working capability from the start. In the current effort, 
also, the concentration has been placed on the communication 
of data between engineers concerned with the design of 
buildings, rather than architects or the construction or 
operation phases of the building process. The reasons for 
the emphasis on the engineer rather than the architectural 
aspects of design are twofold. First, the author is in 
engineer rather than an architect. But more si p;ni f icantly, 
architecture is an atheoretical discipline. An architect 
considers himself to be an artist working in a technical 
industry. The consequence of this is that architects 
structure and treat data differently from the way engineers 
do. Hence/ while the designers of an architectural computer 
system might not be completely happy with the file structure 
of information that will be considered later, their system 
could still be capable of feeding Information regarding 
geometry and materials to the data base. These two 



19 



Information areas are key components in many of the 
engineering design areas. 

Future Work 

There are two major areas to be investigated in the 
implementation of an ICES building design subsystem: data 
management and file structure. 

The concept of using data as the integrating bond for 
a building system leads directly to the fundamental question 
of data management. The general problem of data management 
has been the object of much computer research and 
development over the past decade. The levelooment of the 
generalized data management systems leads one to consider 
their value for the problem of data management in the 
building context, or at least the approorl ateness of their 
approach to a solution for this problem. 

The generalized data management systems have 
addressed themselves directly to the problem of how does one 
manage the computer environment where there exists a large 
corpus of data about some loosely structured logical entity 
(generally a corporate or military operation) which must b« 
developed and used by a group of independent computer 
systems, none of which is responsible for all of the data 
and all of which must share the use of the data. This is 
exactly the problem faced in the building realm. 

While the use of the feneral i ze i data management 



20 



systems in the context of building systems has s.tmp 
drawbacks, the ICE? systems as currently implemented does 
Uave some data management capabilities. The * C F ^ TABLE- li 
system has file structure capabi 1 i ti es and storage and 
retrieval functions. 

The TABLE- 1 I file structuring capabilities are 
particularly appropriate for the problem of storing dynamic 
information in a file on secondary storage. This system, 
like the general i zed data management sys terns, stores 
information in such a manner that its location and 
character! sties are remembered by the system. Further no r? , 
lata are identified by name in such a way that o:*ie need 
merely provide the system with the name and the system is 
able to retrieve not only the value but also information as 
to what the characteristics of the data ar(> (dimensional 
uni ts and computer characteristics). Concent ual 1 y, the 
i nformat ion is structured as a four level tr^e: table, r<v-/, 
column, and list position. 

The feature of having available a file system which 
uniquely identifies and manages data within the system is o r 
primary importance in the area of build inn; systems (as we "' I 
as many other systems ) . The problems of mana» 7 j n?. a growi np 
corpus of information used by completely indeoendent 
computer systmes demands that one consider only a data 
management system capable of treating the information as a 
growing, dynamic entity. The classical approach of file 



21 



structure based on locational conventions is clearly out of 
the question in such a situation. Such an aoproach always 
demands a fixed file large enough to hoi. I the largest anount 
of data one can design for. Furthermore, it is generally 
impossible to identify the condition where data values art* 
missing - where they have not been stored yet. The 
integration of various computer systems for different 
discipline areas requi res that i nformat ion regard in? 
dimensional aspects of the data be maintained as well as the 
convenience of automat ic con vers ion of d (mens ions on 
request. 

The TABLE-II system has the additional feature that 
there are currently available a collection of storage and 
retrieval f unct ions for pass! ng i nformat ion in 31 the r 
direction between an engineering program and a secondary 
storage file. The TABLE-II subsystem is rather unique amnns 
the ICES subsystems: it exists on both the emri nee r-user 
level as a problem oriented lan<\uae;e subsystem and on the 
programmer-user level as the collection of stora.se and 
retr ieval f unct ions . 

The file structure for a computer based information 
system must closely reflect the structure of the dotn .&§. j _t 
is used bv the designers. The file structure for a building 
information system must be based on the characteristics of 
the use of data by the engineers and the architect. Each of 
these people has a responsibility which is uniquely his own. 



'> ? 



The architect is responsible for the geometry and layout cf 
the spaces as we 11 as the specification of the materia Is of 
the walls and other surfaces; the structural engineer is 
res pons ible for the structural f ram.-? r mm i r^ d to sunrort the 
loads in the building; the electrical engineer for the 
distribution of electrical power throughout the building as 
required; the mechanical engineer for the system of air 
ducts for the delivery of hot and col'* air to the spaces and 
the removal of waste air from the system. Each of these 
designers has a realm of data which he develops in 
conjuction with the objectives and requi rements o^ th * 
others connected with the project. 

Thus, while the architect generally has the principal 
concern with windows as an element of form, his decisions on 
windows greatly Influence the heat loads that ar^ the 
responsibility of the mechanical engineer and the amount of 
lighting which is the responsibility of the electrical 
engineer. 

The file structure for a computer based information 
system of building design data must be organized around the 
use of data by the various agents primarily concerned with 
that data, and the data within a file should be structured 
in such a way as to reflect the relational an 1 algorithmic 
structure of the data. The data regarding windows s^o-ild be 
the responsibility of the architect. He is the designer 
primarily responsible for choosing the quality and location 



£C 




UJ 


< 


o 

0. 


Si 

o 




z 


o 


<9 


CO 


CO 


< 


U 


CD 


o 



OOC ic 2 

^ui o J- 

OO H flc 
mO. UJ q 

* CO 
UJ 
O 



UJ 



CO 
O O 

II 

oc <r 
a. o 

CO 
UJ 

o 



_J 


< 


< 


O 


3 




O 

3 


z 
o 


a: 


CO 


H- 


Id 


co 


a 



i 


2 
O 




CTUR 

AME 

RIPTI 


CO 

a 

< 


^ff 


o 


tc ^ 


CO 




H 


u 


i 


co 


a 





/ 



a. 



UJ 



UJ 



i 

>** 

UJ 

cc 
u. 



o 

OC 
O 
< 




z 



0) 
UJ 

a 

z 
< 

3 

CL 

< 



UJ 



> 
oc 






•t 


2* 


i*E 


<o 


-O 


CD uj 


2(0 


O 


ou 




oo 




oc 



< 



a. 

z 
o © 

co co 

< UJ 
CD O 




-J a 2 

K s 2: 

uj < cc 

H J O 

< w . 

S ^t ^ 



a 


< 


< 


1- 


> 


I 




z 


o 


a 






CO 


CO 


< 


Ul 


CD 


a 



I- z 

O H OS 
>Z » 



UJ 

Q 



2t 



of windows. Also the location of Information about thr? 
windows among all of the lata Items which fall into tbe 
realm of the architect should reflect the fact that windows 
are located in walls, walls which delimit two spaces. 

With a file so structured, the mechanical engineer in 
doing heat load analysis can interrogate the data base of 
the architect regarding the room under consideration, asking 
for the U-factors for each of the walls and be told that a 
particular wall has a window of some specific size and that 
the design temperature minimum on the other side of that 
window during the window is -20 degrees Fahrenheit, 
Furthermore, the electrical engineer can query the same file 
of the architect and learn that the room has a window with a 
southern exposure and hence has a calculable flux of 
sunsh ine. 

The macro level file structure proposed for a 
building environment Is outlined in Figure l-U. This 
represents a first effort at a file structure of this sort. 
As work proceeds, further refinements on the various 
sub-files and their relationships will become apparent. 



Mrjf oc; 



1. See especially/ Roos, Daniel, £_i., I CES System , Genera 1 
Descr i pt ion , Report R 67-4 9, Depart nent of Civil Engineering 
(Cambr i dge : Massachusetts Institute of Technology, 19*57), 
and Jordan, Jane, £d.., I CES System , Programmers Reference 
Manual , Report R67-5 0, Department of Civil Engineering 
(Cambr i dge: Massachusetts Institute o c Technology, 19 3 7). 

2. Among the subsystems of ICES are several that are of 
particular concern to the realm of building .lesion and 
construction. These are the STRUDL subsystem, tha PROJECT 
subs y stein, the TABLE subsystem, and the TU I ID subsystem. 
Cf: Logcher, Robert D., £JL al. , ICES STRUDL - 1 I, The 
Structural Oesi gn Language : Engi neeri ng User's Manual , First 
ed i t ion, Report R68-T1, Department of Civil Engineering 
(Cambridge: Massachusetts I nst i tute of Techno 1 oey, 19-58 ) ; 
Logcher, Robert D., and James N. Jackson, ICES TA3LE -I I : hH 
ICES File Storage Subsystem : Engineer ing User's Manual , 
First edition, Report R69-3*+, Department of Civil 

Eng i neeri ng ( Cambr i dge: Massachusetts Institute of 
Technology, 1969); Daniels, Robert L., and E. Jack Mall, 
I CES PROJECT - I I , Project Eng i neeri n.g Control : General 
Descri ot i on . Second edition, Reoort R68-11, Department of 
Civil Engineering (Cambr i dge: Massachusetts Institute of 
Technology, 1968); and Teague, Lavette C. , £JL a±. , A User f s 
Gu i de to BUI LP , Department of Civil Engineering (Cambridge: 
Massachusetts Institute of Technology, 1957 

3. Roos, Daniel, I CES System Design , Second edition 
(Cambridge: MIT Press, 1967). 

b. A relational data structure, as opposed to a structure 
based only on data arrays, is one that represents in the 
computer memory not only data val ues but also data 
rel at i onshi os and st ructure . This is generally accomplished 
by the addition of pointer capabilities to the array feature 
i n order to represent the relations. 

5. Lipner, S. B., "A List Processing System for Engineering 
Applications, 11 IM. S. thesis submitted to the Department of 
Civil Engineering, Massachusetts Institute of Technology, 
1966). 

6. Roos, ICES System Design , Appendix M. 

7. Long, Richard, "Data Transfer In Large Scale Computer 
Systems, 11 (unpubl ished Master's Thesis, Sloan School of 
Management, Massachusetts Institute of Technology, 1963). 



25 



3. "Growing Popul at ion + rjrowi ng Needs = Soaring 
Construction/ 1 Construction M ethods , July, 19U6, p. 26. 

9. Ibid ., p. 27. 

10. Dietz, A. G. H . , The Bui Iding Industry , A report 
prepared for the Commission on Urban Problems, March, 1968. 
Available from Clearinghouse, PB185208. 

11. Ministry of Public Buildings and Works, Profess ional 
CQllabQratlQn la Designing BuMdinKS/ R * n Bui Ming 
Management Handbook, 5 (London: Her Majesty's Stationery 
Office, 1967). 

12. Miller, Charles L., "Decision Makers, 11 Intervipw with 
Charles L. Miller, Computer Decisions , February, 1970, po. 
12-13. 

13. For comparative i nformat ion on comouter capacity and 
performance, see Auerbach Info., Inc., Auerbach Standard Epp 
Reports (Philadelphia: Auerbach Info., Inc., 1969). 

Ik. Computerworld , May 2n, 1970, p. 1. 



UNCLASSIFIED 



Security Classification 



DOCUMENT CONTROL DATA - R&D 

(Security claaailication of title, body of at at red and interning annotation muat be entered when the overall report ia claaaitied) 



1. ORIGINATING AC Tl VI T Y ( Corpormtm author) 

Project MAC 

Massachusetts Institute of Technology 



Zm REPORT SECURITY CLASSIFICATION 

UNCLASSIFIED 



2b. GROUP 

None 



3. REPORT TITLE 



Interactive Design Coordination for the Building Industry 



4. DESCRIPTIVE NOTES (Type ot report and incluaive dote a) 

Technical Memorandum 



S. AUTHOR(S) (Leaf name, tirat name, initial) 

Jackson, James N. 



6. REPORT OATE 

June 22, 1970 



8a. CONTRACT OR GRANT NO. 



N00014-69-A-0276-0002 



ft. PROJECT NO. 



7«. TOTAL NO. OP PAGES 



32 



76. NO. or RCPS 



14 



9a. ORIGINATOR'S REPORT NUMBER(S) 

TM-10 



9b. OTHER REPORT NO(8) (Any other manbara that may be 
aaelgned thia report) 



10. AVAILABILITY/LIMITATION NOTICES 



Distribution of this document is unlimited. 



II. SUPPLEMENTARY NOTES 



12. 



SPONSORING MILITARY ACTIVITY 

Advanced Research Projects Agency 
3D-200 Pentagon 
Washington , D # C . 



13. ABSTRACT 

One of the responses to the need for effective interaction in the 
use of computers for a design project is the supersystem concept 
proposed for ICES, the Integrated Civil Engineering System. The 
supersystem is defined as the cooperative effort on the part of the 
designers of several problem oriented computer capabilities to 
implement project oriented capabilities by allowing each of, their 
problem oriented subsystems to reference a single file of project 
data. The supersystem would allow design interaction by having each 
of the problem oriented computer subsystems reference a single file 
of information specifying the project. 

Future work in the application of computers to interactive and 
project oriented design in the building industry will have to 
concentrate on the file structure to be used in the implementation of 
— a computer building design oupc r gyafec t n. 

14. KEY WORLDS 



Computers, Building design, Building construction, ICES System, 
Structural analysis 



DD 



FORM 
1 NOV •• 



1473 (M.I.T.) 



UNCLASSIFIED 



Security Classification